FHIR © HL7.org  |  Server Home  |  FHIR Server FHIR Server 3.4.11  |  FHIR Version n/a  User: [n/a]

Resource CodeSystem/FHIR Server from package hl7.terminology#current (31 ms)

Package hl7.terminology
Type CodeSystem
Id Id
FHIR Version R5
Source http://terminology.hl7.org/https://build.fhir.org/ig/HL7/UTG/CodeSystem-resource-security-category.html
Url http://terminology.hl7.org/CodeSystem/resource-security-category
Version 1.0.0
Status draft
Date 2020-04-09T21:10:28+00:00
Name ResourceSecurityCategory
Title ResourceSecurityCategory
Experimental False
Realm uv
Authority hl7
Description Provides general guidance around the kind of access Control to Read, Search, Create, Update, or Delete a resource.
Copyright This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
Content complete
valueSet http://terminology.hl7.org/ValueSet/resource-security-category

Resources that use this resource

ValueSet
resource-security-category ResourceSecurityCategory

Resources that this resource uses

No resources found



Narrative

Note: links and images are rebased to the (stated) source

Generated Narrative: CodeSystem resource-security-category

Last updated: 2020-04-09 21:10:28+0000

This case-sensitive code system http://terminology.hl7.org/CodeSystem/resource-security-category defines the following codes:

CodeDisplayDefinition
anonymous Anonymous READ Access ResourceThese resources tend to not contain any individual data, or business sensitive data. Most often these Resources will be available for anonymous access, meaning there is no access control based on the user or system requesting. However these Resources do tend to contain important information that must be authenticated back to the source publishing them, and protected from integrity failures in communication. For this reason server authenticated https (TLS) is recommended to provide authentication of the server and integrity protection in transit. This is normal web-server use of https.
business Business Sensitive ResourceThese Resources tend to not contain any individual data, but do have data that describe business or service sensitive data. The use of the term Business is not intended to only mean an incorporated business, but rather the more broad concept of an organization, location, or other group that is not identifable as individuals. Often these resources will require some for of client authentication to assure that only authorized access is given. The client access control may be to individuals, or may be to system identity. For this purpose possible client authentication methods such as: mutual-authenticated-TLS, APIKey, App signed JWT, or App OAuth client-id JWT For example: a App that uses a Business protected Provider Directory to determine other business endpoint details.
individual Individual Sensitive ResourceThese Resources do NOT contain Patient data, but do contain individual information about other participants. These other individuals are Practitioners, PractitionerRole, CareTeam, or other users. These identities are needed to enable the practice of healthcare. These identities are identities under general privacy regulations, and thus must consider Privacy risk. Often access to these other identities are covered by business relationships. For this purpose access to these Resources will tend to be Role specific using methods such as RBAC or ABAC.
patient Patient SensitiveThese Resources make up the bulk of FHIR and therefore are the most commonly understood. These Resources contain highly sesitive health information, or are closely linked to highly sensitive health information. These Resources will often use the security labels to differentiate various confidentiality levels within this broad group of Patient Sensitive data. Access to these Resources often requires a declared Purpose Of Use. Access to these Resources is often controlled by a Privacy Consent.
not-classified Not classifiedSome Resources can be used for a wide scope of use-cases that span very sensitive to very non-sensitive. These Resources do not fall into any of the above classifications, as their sensitivity is highly variable. These Resources will need special handling. These Resources often contain metadata that describes the content in a way that can be used for Access Control decisions.

Source

{
  "resourceType" : "CodeSystem",
  "id" : "resource-security-category",
  "meta" : {
    "lastUpdated" : "2020-04-09T21:10:28.568+00:00"
  },
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p class=\"res-header-id\"><b>Generated Narrative: CodeSystem resource-security-category</b></p><a name=\"resource-security-category\"> </a><a name=\"hcresource-security-category\"> </a><a name=\"resource-security-category-en-US\"> </a><div style=\"display: inline-block; background-color: #d9e0e7; padding: 6px; margin: 4px; border: 1px solid #8da1b4; border-radius: 5px; line-height: 60%\"><p style=\"margin-bottom: 0px\">Last updated: 2020-04-09 21:10:28+0000</p></div><p>This case-sensitive code system <code>http://terminology.hl7.org/CodeSystem/resource-security-category</code> defines the following codes:</p><table class=\"codes\"><tr><td style=\"white-space:nowrap\"><b>Code</b></td><td><b>Display</b></td><td><b>Definition</b></td></tr><tr><td style=\"white-space:nowrap\">anonymous<a name=\"resource-security-category-anonymous\"> </a></td><td>Anonymous READ Access Resource</td><td>These resources tend to not contain any individual data, or business sensitive data. Most often these Resources will be available for anonymous access, meaning there is no access control based on the user or system requesting. However these Resources do tend to contain important information that must be authenticated back to the source publishing them, and protected from integrity failures in communication. For this reason server authenticated https (TLS) is recommended to provide authentication of the server and integrity protection in transit. This is normal web-server use of https.</td></tr><tr><td style=\"white-space:nowrap\">business<a name=\"resource-security-category-business\"> </a></td><td>Business Sensitive Resource</td><td>These Resources tend to not contain any individual data, but do have data that describe business or service sensitive data. The use of the term Business is not intended to only mean an incorporated business, but rather the more broad concept of an organization, location, or other group that is not identifable as individuals. Often these resources will require some for of client authentication to assure that only authorized access is given. The client access control may be to individuals, or may be to system identity. For this purpose possible client authentication methods such as: mutual-authenticated-TLS, APIKey, App signed JWT, or App OAuth client-id JWT For example: a App that uses a Business protected Provider Directory to determine other business endpoint details.</td></tr><tr><td style=\"white-space:nowrap\">individual<a name=\"resource-security-category-individual\"> </a></td><td>Individual Sensitive Resource</td><td>These Resources do NOT contain Patient data, but do contain individual information about other participants. These other individuals are Practitioners, PractitionerRole, CareTeam, or other users. These identities are needed to enable the practice of healthcare. These identities are identities under general privacy regulations, and thus must consider Privacy risk. Often access to these other identities are covered by business relationships. For this purpose access to these Resources will tend to be Role specific using methods such as RBAC or ABAC.</td></tr><tr><td style=\"white-space:nowrap\">patient<a name=\"resource-security-category-patient\"> </a></td><td>Patient Sensitive</td><td>These Resources make up the bulk of FHIR and therefore are the most commonly understood. These Resources contain highly sesitive health information, or are closely linked to highly sensitive health information. These Resources will often use the security labels to differentiate various confidentiality levels within this broad group of Patient Sensitive data. Access to these Resources often requires a declared Purpose Of Use. Access to these Resources is often controlled by a Privacy Consent.</td></tr><tr><td style=\"white-space:nowrap\">not-classified<a name=\"resource-security-category-not-classified\"> </a></td><td>Not classified</td><td>Some Resources can be used for a wide scope of use-cases that span very sensitive to very non-sensitive. These Resources do not fall into any of the above classifications, as their sensitivity is highly variable. These Resources will need special handling. These Resources often contain metadata that describes the content in a way that can be used for Access Control decisions.</td></tr></table></div>"
  },
  "url" : "http://terminology.hl7.org/CodeSystem/resource-security-category",
  "identifier" : [
    {
      "system" : "urn:ietf:rfc:3986",
      "value" : "urn:oid:2.16.840.1.113883.4.642.1.1404"
    }
  ],
  "version" : "1.0.0",
  "name" : "ResourceSecurityCategory",
  "title" : "ResourceSecurityCategory",
  "status" : "draft",
  "experimental" : false,
  "date" : "2020-04-09T21:10:28+00:00",
  "publisher" : "Health Level Seven International",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://hl7.org"
        },
        {
          "system" : "email",
          "value" : "hq@HL7.org"
        }
      ]
    }
  ],
  "description" : "Provides general guidance around the kind of access Control to Read, Search, Create, Update, or Delete a resource.",
  "copyright" : "This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html",
  "caseSensitive" : true,
  "valueSet" : "http://terminology.hl7.org/ValueSet/resource-security-category",
  "content" : "complete",
  "concept" : [
    {
      "code" : "anonymous",
      "display" : "Anonymous READ Access Resource",
      "definition" : "These resources tend to not contain any individual data, or business sensitive data. Most often these Resources will be available for anonymous access, meaning there is no access control based on the user or system requesting. However these Resources do tend to contain important information that must be authenticated back to the source publishing them, and protected from integrity failures in communication. For this reason server authenticated https (TLS) is recommended to provide authentication of the server and integrity protection in transit. This is normal web-server use of https."
    },
    {
      "code" : "business",
      "display" : "Business Sensitive Resource",
      "definition" : "These Resources tend to not contain any individual data, but do have data that describe business or service sensitive data. The use of the term Business is not intended to only mean an incorporated business, but rather the more broad concept of an organization, location, or other group that is not identifable as individuals. Often these resources will require some for of client authentication to assure that only authorized access is given. The client access control may be to individuals, or may be to system identity. For this purpose possible client authentication methods such as: mutual-authenticated-TLS, APIKey, App signed JWT, or App OAuth client-id JWT For example: a App that uses a Business protected Provider Directory to determine other business endpoint details."
    },
    {
      "code" : "individual",
      "display" : "Individual Sensitive Resource",
      "definition" : "These Resources do NOT contain Patient data, but do contain individual information about other participants. These other individuals are Practitioners, PractitionerRole, CareTeam, or other users. These identities are needed to enable the practice of healthcare. These identities are identities under general privacy regulations, and thus must consider Privacy risk. Often access to these other identities are covered by business relationships. For this purpose access to these Resources will tend to be Role specific using methods such as RBAC or ABAC."
    },
    {
      "code" : "patient",
      "display" : "Patient Sensitive",
      "definition" : "These Resources make up the bulk of FHIR and therefore are the most commonly understood. These Resources contain highly sesitive health information, or are closely linked to highly sensitive health information. These Resources will often use the security labels to differentiate various confidentiality levels within this broad group of Patient Sensitive data. Access to these Resources often requires a declared Purpose Of Use. Access to these Resources is often controlled by a Privacy Consent."
    },
    {
      "code" : "not-classified",
      "display" : "Not classified",
      "definition" : "Some Resources can be used for a wide scope of use-cases that span very sensitive to very non-sensitive. These Resources do not fall into any of the above classifications, as their sensitivity is highly variable. These Resources will need special handling. These Resources often contain metadata that describes the content in a way that can be used for Access Control decisions."
    }
  ]
}

XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.